I'd be interested to add a CI job running in almalinux:8 to check this, based on https://github.com/truffleruby/truffleruby/blob/master/tool/build-with-old-glibc/Dockerfile
Does that sound OK?

I added a CI job, before the fix it fails as expected:
https://github.com/ruby/prism/actions/runs/23650997866/job/68895672649?pr=4051
and after it passes.

@kddnewton That seems a lot more involved, could we merge this first?

If you don't like the CI job I can remove it, but it seems better than nothing.

For context, this is pretty much blocking a TruffleRuby release, as the release fails to build due to this.

I would say it is not arbitrary, it is the oldest free RHEL-like distribution which is not EOL yet, see https://endoflife.date/almalinux

I have removed the CI job as I don't want that to block this fix.
I saved it on another branch: eregon@e1f1364

The amount of jobs that are tested in ruby is huge, I agree that replicating that isn't really desirable. I think it's good enough to happen just on sync, I don't think not having it has done much harm yet.

I'm ok with the added CI job. I don't really care which specific version it is or why it was chosen. It's within what ruby is testing and is more for the benefit of truffleruby than anything else.

I'm also thinking whether testing so many compilers wouldn't add much CI time, there are 11 and that's just gcc, there are 18+ more for clang at a glance.
The gcc ones appear to run in the same CI job though so maybe it isn't that slow?
It would also mean depending on ghcr.io/ruby/ruby-ci-image:$TAG.
The fact the gcc versions used there don't match what common Linux distributions use doesn't seem ideal (the 8.5 vs 8.4 mismatch mentioned here).
In any case that seems like a much bigger thing to figure out, hence why I removed the CI job from this PR.

I can't imagine it would add too much time, because I don't think we would run the tests, just ensure it compiles without warnings/errors.